\chapter{Resutados}
Esse capítulo mostra os resultados obtidos com os testes descritos no capítulo anterior. Os resultados serão mostrados graficamente
para uma melhor compreensão e as ferramentas serão comparadas e comentadas, desenvolvendo uma melhor noção do potencial do ataque.

\section{Primeira versão da ferramenta}
As ferramentas foram brevemente descritas no capítulo anterior, para uma breve comparação pode-se usar a tabela ~\ref{tab:tools} 
como referência. A primeira versão da ferramenta foi confeccionada usando o \emph{framework}/API QT\textregistered. A ferramenta
segue a estrutura geral similar as outras três ferramentas descritas, porém respeita a ordem de envio de pacotes (figura ~\ref{fig:fluxo}). Os 
\emph{handshakes} feito por essa
versão são feitos de forma natural, a ferramenta começa o processo de \emph{handshake} e espera o servidor responder. O servidor 
responde
e só então a ferramenta continua.
Essa característica deixa a ferramenta ociosa enquanto espera respostas do servidor, esse breve período ocioso significa que o servidor
está ocupado processando a última requisição da ferramenta. Esse período é justamente o intuito da ferramenta, gastar os recursos
do servidor.

Seguir o \emph{design} do protocolo é o esperado de qualquer cliente, logo a ferramenta possui menor chance de ser descoberta como 
maliciosa. Esse tempo ocioso, porém, indica que o atacante não está usando todo seu poder para incapacitar o servidor;
há uma leve dilema entre uma ferramenta mais discreta ou mais eficiente.

Para servir de referência, foi medido o tempo de resposta do servidor préviamente ao ataque. O servidor normalmente demora cerca de
1.964 milisegundos para responder a uma requisição, possui cerca de 50 conexões disponíveis de um total de 50 conexões e tem um 
consumo de CPU em cerca de 0.09\%. Essas medições foram feitas com as ferramentas descritas no capítulo anterior. As figuras ~\ref{fig:f1-absoluto}
e ~\ref{fig:f1-tempo} mostram, respectivamente, o tempo que as requisições começaram a tomar e a relação proporcional do aumento. Esse aumento proporcional
é dado pela razão entre o novo tempo e o tempo pré-ataque, dando uma medida de quantas vezes o ataque aumentou o tempo de resposta.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.7]{figuras/f1-absoluto.png}}
\caption{Gráfico com os tempos médios de duração de handshake durante o ataque com a primeira versão da ferramenta.}
\label{fig:f1-absoluto}
\end{figure}

\begin{figure}[H]
\centerline{\includegraphics[scale=0.8]{figuras/f1-tempo.png}}
\caption{Gráfico com o aumento proporcional do tempo de resposta gerado pela primeira versão da ferramenta.}
\label{fig:f1-tempo}
\end{figure}

Pode-se ver na figura ~\ref{fig:f1-tempo} o tempo decorrido de ataque no eixo horizontal, e no eixo vertical o aumento do tempo de resposta
de cada requisição. O gráfico mostra que ao executar a ferramenta usando 50 \emph{threads} o servidor não está preparado e acaba
por ter um grande aumento no tempo de resposta, quase que 120 vezes maior que o tempo normal de resposta. Porém, servidores como o
Apache\textregistered são dinâmicos, eles usam alocação dinâmica para aumentar recursos em tempo real e garantir sua qualidade de serviço.
Olhando o funcionamento do ataque percebe-se que o mesmo demostrou-se bem ocilante, porém o aumento do tempo de resposta é real, testes com
um maior número de \emph{threads} mostraram que qualquer requisição feita por um cliente, por mais simples que seja, têm seu tempo aumentado entre 
20 e 40 vezes. Esse aumento pode afetar clientes usando de sistemas que usem de aplicações envolvendo tempo real, porém mesmo com o aumento o servidor
continua ativo e respondendo, logo a ferramenta se encaixaria como negação de serviço parcial.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.8]{figuras/f1-cpu.png}}
\caption{Gráfico com o consumo de CPU gerado pela primeira versão da ferramenta.}
\label{fig:f1-cpu}
\end{figure}

O gráfico da figura ~\ref{fig:f1-cpu} mostra que o ataque aumenta o consumo de CPU de 0.09\% para valores um pouco maiores, cerca de 0.5\%.
O aumento moustrou-se pouco, não sendo muito relevante para uma negação de serviço. Valores tão baixos no consumo de CPU não chegam a
explicar o aumento relativo no tempo de resposta, provavelmente o consumo é intermitente tendo seu pico apenas em momentos onde o servidor
tem que decifrar o pacote com 'lixo' e a ferramenta de medição acaba por não captar esses picos e mostra apenas o consumo estável do CPU.
Uma outra possibilidade, é a de que o caráter levemente volumétrico da ferramenta(as várias \emph{threads} atacando constantemente) esteja causando parte do atraso no tempo de resposta.
Ainda olhando o gráfico, pode-se reparar que o consumo durante o teste com 50 \emph{threads} foi bem superior, assim como a medição do
tempo de resposta. Essa correlação mostra que o aumento significativo do tempo de resposta está intimamente ligada ao gasto de CPU.

\begin{table}[H]
\caption{Estado das conexões ocupadas durante ataque com a ferramenta versão 1.}
\centering
\label{tab:f1-conexoes}
\begin{tabular}{|c|c|c|c|}
\hline
\multicolumn{4}{|c|}{Conexões ocupadas (ferramenta versão 1)}\\
\hline
{}	&\multicolumn{3}{|c|}{Tempo decorrido}\\
\hline
Número de \emph{threads}	&5 minutos	&10 minutos	&15 minutos\\
\hline
50 threads	&41/50	&39/50	&40/50\\
100 threads	&49/50	&49/50	&49/50\\
500 threads	&41/50	&41/50	&41/50\\
1000 threads	&41/50	&41/50	&42/50\\
5000 threads	&42/50	&42/50	&42/50\\
10000 threads	&42/50	&42/50	&41/50\\
\hline
\end{tabular}
\end{table}

A tabela ~\ref{tab:f1-conexoes} mostra as conexões ocupadas e o número máximo de conexões disponíveis
\footnote{A tabela mostra o número de conexões efetivamente ocupadas, por maior que seja o 
número de \emph{threads} muitas das conexões já foram encerradas ou estão sendo encerradas, logo o número de conexões ocupadas
não alcançam as conexões máximas. Além disso, servidores \emph{web} usam de processos de escalonamento e filas para receber 
conexões de novos clientes.}, como dito préviamente o servidor
usado é dinâmico e por isso esse número de conexões pode aumentar se for necessário, porém consome mais recursos. Observando a tabela
pode-se observar que grande parte das conexões fica ocupada, mas é seguido o limite de 50 conexões no servidor que não é considerado
um limite alto. Um maior número de conexões implica em um maior gasto de memória por parte do servidor, o que não é o foco desse tipo de ataque,
porém um maior número de conexões indica que os clientes conectados ao servidor terão que juntos 'dividir' o gasto de CPU inteiro do servidor
(seguindo uma política de escalonamento definida).

A ferramenta mostrou um certo impacto no servidor, mas nada muito relevante. O servidor conseguiu se adaptar bem ao ataque deixando o
cliente com prejuízos mínimos, relevante apenas para alguns tipos de aplicações.

\section{Segunda versão da ferramenta}
A segunda versão da ferramenta tenta maximizar o gasto de CPU do servidor tentando mantê-lo sempre ocupado, para isso sempre que possível
a ferramenta manda as requisições do \emph{handshake}. A ferramenta manda primeiramente o \emph{client hello} (para mais detalhes rever 
o capítulo sobre TLS/SSL) e logo em seguida e ininterruptamente manda o \emph{client key exchange}, \emph{change cipher spec} e \emph{encrypted handshake message}.
O servidor então considera que o cliente foi muito rápido e começa a processar as respostas, ou pode, também, ocorrer em alguns casos 
do servidor considerar a mensagem como errada e encerrar a conexão. Em caso de falhas, ou da conexão ser encerrada, a ferramenta 
restabelece a conexão e começa o processo novamente. A idéia é verificar a conexão, caso esteja ativa despejar o mais rápido possível os
\emph{handshakes} sem permitir descanso ao servidor. Em todos os outros méritos a ferramenta segue o fluxograma da figura ~\ref{fig:fluxo}.

Os gráficos das figuras abaixo mostram o aumento do tempo de resposta do servidor em relação a antes do ataque.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.8]{figuras/f2-absoluto.png}}
\caption{Gráfico com os tempos médios de duração de handshake durante o ataque com a segunda versão da ferramenta.}
\label{fig:f2-absoluto}
\end{figure}

\begin{figure}[H]
\centerline{\includegraphics[scale=0.8]{figuras/f2-tempo.png}}
\caption{Gráfico com o aumento proporcional do tempo de resposta gerado pela segunda versão da ferramenta.}
\label{fig:f2-tempo}
\end{figure}

Nos gráficos ~\ref{fig:f2-tempo}~\ref{fig:f2-absoluto} observa-se que novamente a ferramenta rodando com 50 \emph{threads} teve um primeiro resultado bem elevado e depois abaixa ficando 
bem próxima dos testes com maior número de \emph{threads}. Nessa versão, entretanto, o acrécimo é bem maior, a versão com 50 \emph{threads}
chegou a atrasar as requisições do cliente no seu pico em quase 900 vezes. Os testes com número diferentes de \emph{threads} ficaram
mais estáveis, dando-se destaque as versões com 1000 e 5000 \emph{threads}. Esses testes tiveram um bom desempenho quase alcançando
um aumento de 200 vezes. Esse aumento começa a ser significativo para o ataque, uma requisição simples de uma página que antes demorava
alguns milisegundos agora demora segundos.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.8]{figuras/f2-cpu.png}}
\caption{Gráfico com o consumo de CPU gerado pela segunda versão da ferramenta.}
\label{fig:f2-cpu}
\end{figure}

A figura ~\ref{fig:f2-cpu} do gráfico acima mostra o consumo de CPU que também aumentou em relação a primeira versão da ferramenta,
as medições mostraram que aumento do gasto de CPU foi proporcional ao aumento do número de \emph{threads}. O consumo máximo obtido
com a primeira versão foi 9\%, com essa versão obtêm se um percentual maior que 200\% do consumo\footnote{

Valores acima de 100\% são devido ao consumo de CPU maior do que o máximo reservado ao uso do servidor, porém com comportamento dinâmico
e uso de multiplos \emph{cores} permite um consumo maior do que a medida de 100\%.

}. O elevado consumo de CPU mostra
que ataques do genêro são realmente viáveis. 

Valores de consumo de CPU acima de 100\% se dão devido ao fato do servidor alocar dinamicamente novos processos para conseguir suportar
a demanda exigida, o que acaba por usar de mais de um núcleo do processador.

\begin{table}[H]
\caption{Estado das conexões ocupadas durante ataque com a ferramenta versão 2.}
\centering
\label{tab:f2-conexoes}
\begin{tabular}{|c|c|c|c|}
\hline
\multicolumn{4}{|c|}{Conexões ocupadas (ferramenta versão 2)}\\
\hline
{}	&\multicolumn{3}{|c|}{Tempo decorrido}\\
\hline
Número de \emph{threads}	&5 minutos	&10 minutos	&15 minutos\\
\hline
50 threads	&42/50	&41/50	&42/50\\
100 threads	&42/50	&43/50	&42/50\\
500 threads	&41/50	&42/50	&42/50\\
1000 threads	&41/50	&42/50	&42/50\\
5000 threads	&41/50	&42/50	&42/50\\
10000 threads	&42/50	&41/50	&41/50\\
\hline
\end{tabular}
\end{table}

A tabela mostra que o número de conexões máximas não chegou a aumentar e o número de conexões ocupadas parece permanecer o mesmo. Não
se pode dizer muito das conexões, porém o aumento de CPU e do tempo de resposta ainda mostraram que o ataque pode ser bem efetivo.


\section{Versão da ferramenta com libevent e RSA}
As ferramentas que usam da API libevent obtiveram um maior desempenho. A API é especializada em chamadas e
controles de evento do sistema operacional, como o uso de \emph{sockets} e de funções de rede, além disso ela é especializada no tratamento
de funções por evento e no uso de processos simultâneos~\cite{libevent2}. Dados essas especialidades da API o casamento com a ferramenta
foi bem efetivo, pois a grosso modo a ferramenta não passa de várias funções de rede(chamadas de sistema) executando simultaneamente e o
mais rápido possível.
A ferramenta e a API funcionam baseadas em eventos, assim que a ferramenta detecta um evento ela já dispara o próximo evento escolhido. 
Assim que uma mensagem do servidor é recebida a resposta já está na iminência de ser enviada(próximo evento). Além disso, execuções simultâneas usando
\emph{threads} tem um custo elevado de CPU e memória, a API escolhe a melhor e mais rápida opção de escalonamento para realizar eventos 
simultâneos o mais rápido possível, possuindo menos custo computacional que as \emph{threads}.
Esta versão da ferramenta usa apenas de \emph{cipher suites} com RSA, justamente para se ter a comparação com o \emph{forward secrecy}, a ferramenta
como já mencionado também segue o protocolo a risco, com mensagens alternadas entre cliente e servidor sendo respeitadas.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.7]{figuras/f3-absoluto.png}}
\caption{Gráfico com os tempos médios de duração de handshake durante o ataque com a versão da ferramenta usando libevent e RSA.}
\label{fig:f3-absoluto}
\end{figure}

\begin{figure}[H]
\centerline{\includegraphics[scale=0.8]{figuras/f3-tempo.png}}
\caption{Gráfico com o aumento proporcional do tempo de resposta gerado pela versão da ferramenta com libevent e RSA. Nota-se o termo `clientes`
para se referir as múltiplas instâncias usadas pela API.}
\label{fig:f3-tempo}
\end{figure}

As figuras ~\ref{fig:f3-tempo}~\ref{fig:f3-absoluto} mostram que a versão do ataque conseguiu ser mais eficiente que todas as outras ferramentas testadas até agora, as 
execuções com 1000 e 10000 clientes/instâncias foram bem melhores e chegaram quase a um aumento de 2500 vezes no tempo normal para o \emph{handshake}. As outras execuções entretando ficaram
com um desempenho menor do que 200 vezes. Essa diferença discrepante ao se variar o número de clientes acaba por mostrar que o número
de clientes para o ataque deve ser calculado previamente, o consumo de memória da máquina atacante provavelmente é o responsável por
essa flutuação no gráfico, porém o aumento do tempo de resposta ainda é aceitável e comparável as ferramentas usando \emph{threads}.


\begin{figure}[H]
\centerline{\includegraphics[scale=0.8]{figuras/f3-cpu.png}}
\caption{Gráfico com o consumo de CPU gerado pela versão da ferramenta com libevent e RSA.}
\label{fig:f3-cpu}
\end{figure}

O consumo de CPU mostrado na figura ~\ref{fig:f3-cpu} mostra que quase todas as medições feitas forçaram o CPU a um consumo maior que 100\%,
o que é bem preocupante para o servidor. Mas mesmo com esse alto consumo, os maiores valores alcançados foram entre 140\% e 160\%, o que representa
números menores que na segunda versão da ferramenta usando threads. A demora no tempo de resposta está ligada ao consumo excessivo de CPU
por parte do servidor, entretanto essa ferramenta possuiu um maior tempo de resposta e um menor gasto de CPU em relação a segunda versão da ferramenta.
Essa diferença está bem explicada pelo número de conexões, como a API libevent permite maior rapidez nas funções de rede e maior processamento
paralelo, o número de clientes ativos e efetivamente ocupando conexões é maior. Mais detalhes podem ser vistos na tabela ~\ref{tab:f3-conexoes} abaixo.


\begin{table}[H]
\caption{Estado das conexões ocupadas durante ataque com a ferramenta libevent e RSA.}
\centering
\label{tab:f3-conexoes}
\begin{tabular}{|c|c|c|c|}
\hline
\multicolumn{4}{|c|}{Conexões ocupadas (ferramenta com libevent e RSA)}\\
\hline
{}	&\multicolumn{3}{|c|}{Tempo decorrido}\\
\hline
Número de \emph{instâncias/clientes}	&5 minutos	&10 minutos	&15 minutos\\
\hline
50 clientes	&46/75	&48/75	&48/75\\
100 clientes	&62/100	&62/100	&67/100\\
500 clientes	&142/150	&132/150	&136/150\\
1000 clientes	&143/150	&129/150	&142/150\\
5000 clientes	&147/150	&129/150	&144/150\\
10000 clientes	&146/150	&108/150	&133/150\\
\hline
\end{tabular}
\end{table}

Como mostrado na tabela~\ref{tab:f3-conexoes}, o número de conexões máximas do servidor aumentou dinâmicamente, originalmente o servidor 
começa com 50 conexões disponíveis, nos testes com a ferramenta usando a libevent o número de conexões começou direto em 75 pois mesmo com apenas 50
clientes o servidor não estava conseguindo gerenciar tantas conexões. Posteriormente o número de conexões aumenta para 75 e depois para 150,
onde permanece estabilizado. Esse maior número de conexões máximas indica que o atacante estava conseguindo efetuar mais conexões devido
a maior agilidade no seu mecanismo de paralelismo e envio de pacotes, pois o mesmo número de clientes/intâncias confere com o mesmo número de \emph{threads} das outras ferramentas.
Esse aumento se dá exclusivamente ao uso da API libevent.

\section{Versão da ferramenta com libevent e Diffie \& Hellman}
A última ferramenta usa da API libevent e de \emph{cipher suites} usando o protocolo de troca de chaves Diffie \& Hellman efêmero
para colocar à prova se o \emph{perfect foward secrecy} traz consigo consequências negativas. A ferramenta foi feita no mesmo molde
da ferramenta anterior (RSA) e respeitando a troca de mensagens intercaladas entre cliente-servidor, porém usa apenas de \emph{perfect foward secrecy}.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.75]{figuras/f4-absoluto.png}}
\caption{Gráfico com os tempos médios de duração de handshake durante o ataque com a versão da ferramenta usando libevent e Diffie \& Hellman(\emph{Perfect Foward Secrecy}).}
\label{fig:f4-absoluto}
\end{figure}

\begin{figure}[H]
\centerline{\includegraphics[scale=0.75]{figuras/f4-tempo.png}}
\caption{Gráfico com o aumento proporcional do tempo de resposta gerado pela versão da ferramenta com libevent e Diffie \& Hellman.}
\label{fig:f4-tempo}
\end{figure}

Na figura ~\ref{fig:f4-tempo} pode-se observar que os valores estão bem mais altos que comparado a outras ferramentas. A medição feita
com 1000 clientes/instâncias chega a aumentar o tempo de resposta em 10900 vezes, o que dá um bom tempo de espera para o cliente, ainda mais se
tratando de uma simples requisição de uma página de poucos bytes. As outras medições também tiveram bons resultados, a medição com 10000
clientes ficou com um acrécimo sempre acima de 1000 vezes o valor original, já as outras medições tiveram valores similares as ferramentas
usando \emph{threads}. 

A grande variação entre as diferentes medições ressalta que esse ataque necessita de uma calibração de parâmetros, pois o ataque possui
muitas ocilações e diferentes números de clientes/instâncias fazem toda a diferença, como pode-se observar nos gráficos já mostrados. A escolha de testar
os ataques para diferentes números de clientes e \emph{threads} é justamente para prever em quais faixas de parâmetros a máquina atacante
consegue causar mais impacto ao servidor. Realizar novos testes na ferramenta com os parâmetros em faixas de valores próximos aos melhores
resultados pode inclusive revelar melhores resultados e mais dados sobre o ataque, porém testes exaustivos para alcançar melhores resultados
fogem do escopo deste documento. Este documento preza apenas em alertar sobre a possibilidade de um ataque e mostrá-lo à comunidade,
desenvolver e evoluir constantemente o ataque está longe da sua índole.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.8]{figuras/f4-cpu.png}}
\caption{Gráfico com o consumo de CPU gerado pela versão da ferramenta com libevent e Diffie \& Hellman.}
\label{fig:f4-cpu}
\end{figure}

O consumo de CPU da ferramenta possui os mesmos moldes da ferramenta usando de RSA, como pode-se averiguar na figura ~\ref{fig:f4-cpu}
acima. Entretanto, o consumo usando a ferramenta tem um comportamento decrescente, quanto menor o número de clientes maior o consumo de CPU
e quanto maior o número de clientes menor o consumo. Ao se observar a figura ~\ref{fig:f4-tempo}(referente aos tempos de resposta),
os maiores aumentos nas respostas
são de testes com maior número de clientes, 1000 e 10000 clientes. 

Observando a ferramenta com a API libevent e RSA, pode-se reparar um leve tendência decrescente no consumo de CPU, porém o padrão é menos
claro que no gráfico acima. Comparando os padrões nas ferramentas que usam \emph{threads} e QT\textregistered, nota-se que o padrão é inverso,
possuindo comportamento crescente. Tal comportamento se deve ao maior sucesso das ferramentas usando a API libevent, pois com
maior número de conexões e maior gasto computacional o servidor sobrecarregado tenta alocar dinamicamente mais recursos na tentativa de suportar
a sua demanda.

\begin{table}[H]
\caption{Estado das conexões ocupadas durante ataque com a ferramenta libevent e Diffie \& Hellman.}
\centering
\label{tab:f4-conexoes}
\begin{tabular}{|c|c|c|c|}
\hline
\multicolumn{4}{|c|}{Conexões ocupadas (ferramenta com libevent e DHE)}\\
\hline
{}	&\multicolumn{3}{|c|}{Tempo decorrido}\\
\hline
Número de \emph{instâncias/clientes}	&5 minutos	&10 minutos	&15 minutos\\
\hline
50 clientes	&46/100	&42/100	&48/100\\
100 clientes	&96/150	&95/150	&94/150\\
500 clientes	&144/150	&136/150	&126/150\\
1000 clientes	&134/150	&143/150	&144/150\\
5000 clientes	&143/150	&140/150	&143/150\\
10000 clientes	&141/150	&124/150	&125/150\\
\hline
\end{tabular}
\end{table}

Na tabela ~\ref{tab:f4-conexoes}, que descreve a ferramenta usando de Diffie \& Hellman, o número máximo de conexões começa em 100,
mas por volta de apenas metade permanece ocupada. Em seguida,
o número de conexões aumenta consideravelmente chegando no limite de 150 conexões, com 100 clientes por volta de 90 conexões permanecem
ocupadas. A partir de 500 clientes quase todas as conexões permanecem ocupadas, ficando acima de 120 e perto de 150 conexões máximas.
Nota-se em casos anteriores, que com um número de conexões disponíveis tão baixas o servidor já teria aumentado o número de conexões 
máximas, caracterizando um comportamento diferente.

No geral, as ferramentas usando da API libevent causaram um maior atraso para o cliente(usuário legítimo), que é a medida mais 
confiável da negação de
serviço sofrida. A segunda versão da ferramenta usando de QT\textregistered, entretanto, conseguiu um maior consumo de CPU mas um 
menor
número de conexões. Esse 
gasto
de CPU elevado em relação as ferramentas com libevent mostrou que existe uma correlação entre consumo de CPU e número de conexões 
efetivamente ocupadas,
e que essa relação não é linear. As ferramentas usando libevent obtiveram um maior tempo de resposta mesmo com um consumo de CPU um
pouco
menor que a segunda versão da ferramenta com QT, mostrando que o aumento dos dois parâmetros medidos causa impacto, mas não 
necessariamente
o aumento de apenas um deles é suficiente para dizer o impacto do ataque. 

O ataque em geral se mostrou bem oscilante com o decorrer do tempo. O aumento do tempo de resposta do servidor variou ao longo dos
ataques e não mostrou nenhum padrão aparente, porém seu impacto foi real. O ataque possui um comportamento de difícil previsão, mas
está sempre exaurindo o servidor e por mais que seja difícil prevê-lo os resultados obtidos nas versões usando a API libevent foram
todos altos.

A versão do ataque usando de libevent e \emph{Perfect Foward Secrecy} mostrou-se a mais eficiente das ferramentas e consequentemente
a mais perigosa. Mais detalhes e conclusões sobre os testes realizados serão abordados no próximo capítulo.